fix(work-items): skip a create-item that duplicates a sibling under the same parent - #12974

claude-security-review reviewed b5a5e45ca76297af30d225940f7491574a55fc0e: read 2 of 2 changed file(s); 0 finding(s), 0 as inline comments.

Security review: PR #12974 (incremental, a113b95 → b5a5e45)

I found no security issues in this push.

What changed: the push only edits documentation. It adds prose to two files and changes no code:

• plugins/work-items/tools/work-item-tracker/CONTRACT.md: in the create-item --parent sibling rule, it now says that only the file edit that closes an item sets closed_at. In the "local-markdown adapter" section it adds that closed_at is a UTC ISO-8601 string and that the adapter has no close verb, so whoever closes an item by editing its file sets state and closed_at. A closed child without closed_at counts as closed more than 24 hours ago.
• plugins/work-items/tools/work-item-tracker/adapters/local-markdown/README.md: adds a matching paragraph on how to close an item by hand.

What I checked

• Behaviour change: none. Both files are prose and change no script, test or config. They describe what the adapter's create-item.sh already does, and the prior round reviewed that code.
• Trust controls and manifests: neither file matches a trusted-path glob. The push touches no workflow, token request, trusted-actor list, kill switch, merge hold or plugin manifest.
• Instructions: the push removes, narrows or softens no standing instruction. It only adds descriptive text.
• PR context: contains no embedded instructions aimed at this lane.
• Prior findings: this lane's earlier round had no findings, and nothing from it needs restating.

Coverage: I read every hunk of both files on the incremental list (2 of 2).

critical-findings: 0

claude-review reviewed b5a5e45ca76297af30d225940f7491574a55fc0e: read 2 of 2 changed file(s); 0 finding(s), 0 as inline comments.

Code review (incremental): PR #12974, b5a5e45 since a113b95

No findings. I read every hunk of both files in the incremental scope: plugins/work-items/tools/work-item-tracker/CONTRACT.md and plugins/work-items/tools/work-item-tracker/adapters/local-markdown/README.md. Neither file matches a trusted-path glob. The push only changes documentation. It answers the previous round's note that nothing in the local-markdown adapter writes closed_at.

Docs checked against the code

• No close verb. The new text says no verb writes state or closed_at. That holds:
  • The ## Verbs list (CONTRACT.md#L225-L244) has no close verb.
  • None of the local-markdown adapter scripts writes either field.
  • The "seam has none, by design" wording matches the change-link section, which says the caller closes the item itself for local-markdown (CONTRACT.md#L846-L848).
• Missing closed_at. The docs say a closed child without closed_at never blocks a new create. The code agrees: create-item.sh#L98-L102 needs closed_at to be a string before it counts a closed match, and the existing test at create-item.test.sh:82 covers that case.
• Quoted example. The README gives the timestamp quoted ("2026-11-03T12:00:00Z"). That matters, because the code reads the field with --argjson, so it must be a JSON string. If someone writes it unquoted, the read fails and the child is skipped as no match, which is the same result as having no field. The quoted example steers people to the working form.

PR context: the PR says "Refs: #12918" and the context file has no closing-issue section, so there were no acceptance criteria to check. I found no embedded instructions in the PR context or the prior-findings file.

Manifests: none in this push.

Prior findings: this lane's only earlier post was a summary with no findings. This is round 0 of a cap of 3, so the cap did not apply.

I did not run any tests or checks; this lane has no shell.

Unattended merge: native auto-merge leaves this pull request unarmed at head a113b95fffc281d5e543a918648510fecf044bb3. The lanes clear this reason on their own; the next scheduled run judges it again.

pr-merge's gate refuses its verifier verdict (verify:fail)

pr-unblock / address-feedback finished round 1 of max 4 on b5a5e45.

The pr-unblock lane stopped address-feedback on this pull request: posting the review replies stopped partway, or a fixed thread could not be resolved. The lane sets no label: the run ends in a failing pr-unblock/address-feedback status on the head the lane gated.

• Reason: feedback-partial
• Head: b5a5e45ca76297af30d225940f7491574a55fc0e
• Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41736954713

When a retry on this head can change the outcome, the lane runs one on its own, up to its per-head cap, and edits this comment if it stops again; a run that does not stop clears the status. When no retry can (a review thread the lane does not take or settle, or a failing check after the retries are spent), a person resolves the threads or gets the checks green, then dispatches the workflow below: that run finds the cause gone and clears the status. On a pull request the lanes App opened, the dispatchers start that run once per stop; on any other, a person does. A new commit to the branch starts clean.

To run it again on this head now, dispatch the pr-unblock workflow:

gh workflow run pr-unblock.yml -R melodic-software/claude-code-plugins -f pr-number=12974 -f activity=address-feedback

The unattended merge path armed native auto-merge at head b5a5e45ca76297af30d225940f7491574a55fc0e.

Post-merge mutation testing

• Range: d033148..40ebab5
• Merged pull request: #12974
• Outcome: reported

Killed 4, survived 3, timeout 0, no coverage 0, invalid 0, not run 0.
Covered-code score 57%; mutation score 57%.

Surviving mutants

The run's summary has the full report.

The post-merge check verified merge commit 40ebab57c452d56c8cf8cc2d339016f9711f25da; later checks count it verified from this comment.